REMARKS 



Claims 1-3, 8-13, 18-23, and 26-30 have been amended. Claims 4-5, 14-15, and 
24-25 have been canceled. Claims 1-3, 6-13, 16-23, and 26-30 remain pending in the 
application. Reconsideration is respectfully requested in light of the following remarks. 

Section 101 Rejection : 

The Office Action rejected claims 21-30 under 35 U.S.C. § 101 as allegedly being 
directed to non- statutory subject matter. Applicants respectfully traverse this rejection. 
However, to further prosecution of the present application, claims 21-23 and 26-30 have 
been amended to recite a " non-transitory computer-readable storage medium." (Claims 
24-25 have been canceled). Withdrawal of the § 101 rejection is respectfully requested. 

Section 102(e) Rejection : 

The Office Action rejected claims 1-5, 7-15, 17-25 and 27-30 under 35 U.S.C. § 
102(e) as allegedly being anticipated by Beck et al. (U.S. Patent 6,604,140) (hereinafter 
"Beck"). Applicants respectfully traverse this rejection for at least the reasons stated in 
the previous appeal. Nevertheless, in order to expedite prosecution, Applicant has 
presented the above amendments to further clarify reasons why the current rejection is 
not supported by the evidence of record. 

Regarding claim 1, Beck fails to disclose at least the features of a client, 
implemented by a computer on a network, obtaining a service advertisement from a 
space, where the service advertisement is expressed in a markup language, wherein 
the space comprises a network-accessible repository which stores a plurality of 
service advertisements expressed in the markup language, wherein each of the 
plurality of service advertisements comprises a Uniform Resource Identifier (URI) 
and a markup language schema for a respective service, wherein the URI specifies a 
network address at which the respective service may be accessed, and wherein the 
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markup language schema defines a message interface for accessing the respective 
service, as recited in amended claim 1. 

What Beck actually teaches is a service framework that enables devices to 
discover and use services over a network. Beck's service discovery is based on periodic 
multicasting of service descriptors. Beck teaches that an advertiser retrieves a service to 
advertise, creates a service descriptor and periodically broadcasts the descriptor (Beck, 
column 3, lines 59-64 and column 4, lines 40-50). 

The Office has cited Beck, column 6, lines 1-16 where Beck describes how a 
client requests usage of a service by querying a service registry. However, Beck does not, 
either at the cited passage or elsewhere, teach a client obtaining a service advertisement 
from a space, wherein the space comprises a network-accessible repository which stores 
a plurality of service advertisements as recited in claim 1 . Instead, Beck teaches at the 
cited passage that a client furnishes a description of the requested service and that the 
registry matches this request against service descriptors of known services. If a service 
descriptor in the registry matches the description of the requested service, the registry 
verifies that the service is already loaded, and if not, loads the service. Beck does not 
teach that the registry returns to the client (or that the client downloads) the service 
descriptor, which the Office contends is an advertisement. The client in Beck clearly does 
not obtain this service descriptor from the registry. Instead, Beck teaches, "[t]he process 
of binding a service terminates in step 507 where a reference to the service adaptor is 
returned to the client" (emphasis added, Beck, column 6, lines 22-24). Elsewhere, Beck 
teaches that a service adaptor "provides an additional level of indirection between clients 
and the service" and that the service adaptor is a Java class (Beck, column 5, lines 55-61). 

The Office has also asserted Beck's teachings regarding a service user receiving 
service descriptors multicast over the ad-hoc network by other device. However, Beck 
teaches that it is the service user, not a client, that listens for and receives broadcast 
service descriptors and that the service user saves service descriptors in the registry 
which functions as described above to locate services for requesting clients. Furthermore, 
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a service user receiving service descriptors that are broadcast over the network cannot be 
considered a client obtaining a service advertisement from a space. Receiving a 
descriptor via a network broadcast is not at all the same as a client obtaining 
advertisement from a space comprising a network-addressable storage location. 

Moreover, Beck does not teach that a client obtains a service advertisement from 
a space before receiving a service adaptor; instead, as discussed above, Beck's client 
supplies a service description of a requested service, and the registry finds a matching 
service to load (if not already loaded). The client is then returned a reference to the 
service adaptor. Nowhere does Beck describe a client obtaining a service advertisement 
from a space comprising a network-accessible repository which stores a plurality of 
service advertisements. A client supplying a description of a requested service and, in 
return, receiving a reference to a service adaptor, does not disclose a client obtaining a 
service advertisement from a space comprising a network-accessible repository which 
stores a plurality of service advertisements, as recited in Applicants' claim. Instead, the 
client in Beck queries a service registry to obtain a reference to a service adaptor, which 
cannot be considered a service advertisement as defined in amended claim 1 . 

Further in regard to claim 1, Beck fails to disclose a service advertisement 
comprising a Uniform Resource Identifier (URI) and a markup language schema 
for a respective service, where the URI specifies a network address at which the 
respective service may be accessed, and where the schema defines a message 
interface for accessing the respective service, as recited in amended claim 1. 

The Office cites column 4, lines 40-60 of Beck. However, the cited passage does 
not describe an advertisement that includes a markup language schema that defines a 
message interface for accessing the respective service. Beck teaches that a "service 
descriptor contains information about the service, including the service name and a 
description of its function." Beck also states that an "enhanced service descriptor is a 
service descriptor that also contains the location of the code implementing the service." 
(Beck, column 4, lines 45-50). First, as discussed above, the service descriptor in Beck is 
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not obtained by a client from a space comprising a network-accessible repository which 
stores a plurality of service advertisements. Moreover, Beck does not describe its service 
descriptor as including a markup language schema that defines a message interface for 
accessing the respective service. Instead, Beck teaches that a client uses a Java interface 
for a service to call the methods that the service provides (Beck, column 5, lines 42-46 
and column 6, lines 29-36). Beck specifically teaches that a client calls a method 
provided by the service's interface. Thus, not only does Beck fail to disclose an 
advertisement that includes a markup language schema that defines a message interface 
for accessing the respective service as recited in claim 1 , Beck describes a separate Java 
interface for the service that a "defines the set of operations that the service can perform 
on behalf of a client" (Beck, column 5, lines 42-43). The service descriptor, which the 
Office equates to the advertisement of Applicants' claim, clearly does not include a 
markup language schema that defines a message interface for accessing the respective 
service. 

Beck teaches the use of a Java Interface that "defines the set of operations that the 
service can perform". Beck's Java Interface is clearly separate code and not part of the 
service descriptor, which the Office equates to the service advertisement as recited in 
Applicants' claim. Thus, Beck fails to disclose a service advertisement that includes a 
markup language schema as recited in claim 1 . 

Further in regard to claim 1, Beck fails to disclose a service advertisement 
expressed in a markup language , as recited in amended claim 1. 

Beck does not mention markup languages. Moreover, Beck does not teach that 
the service descriptors, which the Office has equated to claim l's service advertisement, 
are expressed in a markup language. 

Further in regard to claim 1, Beck fails to disclose a service advertisement 
expressed in a markup language , the service advertisement comprising a markup 
language schema for a respective service, and a client sending a first markup 
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language message to the service at a URI specified in the service advertisement, as 
recited in amended claim 1. 

Regarding claim 4, now canceled, the Office cites column 5, lines 46-50 as 
allegedly teaching a schema expressed in a "data representation language." However, the 
cited portion of Beck teaches that a service interface 402 defines the set of operations that 
the service can perform on behalf of a client and that the service interface is a Java 
interface. As is well known in the art, a Java interface is not a markup language schema 
as recited in amended claim 1. Java utilizes bytecodes, which, by definition, cannot in 
any way be considered a markup language. As described in Applicants' specification, and 
as is well understood by anyone of ordinary skill in the art, a markup language (such as 
XML) is a particular type of language used to describe or represent data or content. No 
one of ordinary skill in the art would consider Java to be a markup language. Nowhere 
does Beck mention a markup language schema, and Beck clearly fails to disclose a 
markup language schema included in a service advertisement. 

Further in regard to claim 1, Beck fails to disclose a client sending a first 
markup language message to the service at a URI specified in the service 
advertisement, as recited in amended claim 1. 

Regarding claim 5, now canceled, the Office cites column 5, lines 54-61 and 
column 6, lines 30-39 as allegedly teaching wherein the first message is expressed in a 
"data representation language." The cited portions of Beck describe that once a client has 
bound a service it can use that service by calling a method provided by the service's 
interface and that the service interface forwards the call to the service implementation 
that performs the requested service. Beck also teaches that the service interface and the 
service implementation are Java-based and that the RMI, OSF-RPC and HOP inter- 
process communication protocols are used. Beck does not mention anything about 
markup language messages (such as XML messages). As Beck makes no mention of any 
message expressed in a data representation language, Beck does not teach a client 
sending a first markup language message to the service, as recited in amended claim 1 . 
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Anticipation requires the presence in a single prior art reference disclosure of each 
and every limitation of the claimed invention, arranged as in the claim. M.P.E.P 2131; 
Lindemann Maschinenfabrik GmbH v. American Hoist & Derrick Co., 221 USPQ 481, 
485 (Fed. Cir. 1984). The identical invention must be shown in as complete detail as is 
contained in the claims. Richardson v. Suzuki Motor Co., 9 USPQ2d 1913, 1920 (Fed. 
Cir. 1989). As discussed above, Beck clearly fails to disclose a client reading an 
advertisement from a space, wherein the space comprises a network-addressable storage 
location, wherein the advertisement comprises a Uniform Resource Identifier (URI) and a 
schema, wherein the URI specifies a network address at which a service may be accessed, 
and wherein the schema specifies one or more messages usable to invoke one or more 
functions of the service. 

Therefore, Beck cannot possibly be said to anticipate claim 1. The rejection of 
claim 1 is not supported by the cited art, and removal thereof is respectfully requested. 
Similar remarks also apply to claims 1 1 and 21 . 

Regarding claim 10, Beck fails to disclose the client generating a message 
gate for accessing the service, wherein the message gate is generated according to 
the URI and the markup language schema in the service advertisement, and 
wherein said sending a first markup language message to the service comprises 
sending the message via the message gate, as recited in amended claim 10. 

The Office has cited column 7, lines 34 - 44 of Beck as allegedly teaching the 
client "using the URI and the schema in the advertisement to construct a gate for access 
to the service." However, this passage of Beck does not describe a client generating a 
message gate according to a URI and a markup language schema in an advertisement to 
construct a message gate for accessing a service. Nowhere does Beck describe the client 
using a markup language schema from an advertisement to construct a message gate for 
accessing a service. Instead, Beck teaches that the service registry downloads the service 
interface, adapter and implementation and returns a reference to the client and that the 
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client calls methods provided in the service's interface that forwards the call to the 
service adapter (Beck, column 6, lines 3-24 and lines 29-44). The client does not have to 
generate anything in Beck, and Beck certainly fails to describe a client generating a 
message gate for accessing a service according to a URI and a markup language schema 
in an advertisement. 

In the Examiner's Answer of May 4, 2007, the Office maintains that "Beck does 

disclose the client using the URI and the schema in the advertisement to construct a gate 

for access to the service. The rejection clearly sets forth Beck's construction of a gate for 

access to the service as it cites the use of the service implementation at either side or both 

sides of the data transfer (previously cited column 7, lines 34-44). As discussed above, in 

Beck's system, the client requests a service by querying a service registry in order to 

match a certain service descriptor. The client uses a matched service descriptor to 

download the service functionality. This download includes the service interface, the 

service adapter, and the service implementation which clearly effectuate the functions of 

the service. See previously cited column 6, lines 1-16. This clearly meets the limitation 

of using the advertisement to construct a gate for access to the service. Also it is again 

noted that an enhanced service descriptor contains a URL that is used to access the 

service. See previously cited column 4, lines 40-60." The Office's assertion that Beck 

discloses "the client uses a matched service descriptor to download the service 

functionality" is clearly incorrect. Beck clearly discloses that the service registry, and not 

the client , downloads the service functionality, if necessary. This clearly disclosed in 

Beck, col. 5, lines 9-16 (emphasis added): 

The registry matches this request against descriptors of known services. If 
a service descriptor matches the description of the requested service, the 
registry follows in step 502 where it checks if the service is already loaded 
on the device. If the service is not loaded on the device, the service 
registry follows steps 503, 504 and 505 in order to respectively download 
the service interface, adapter and implementation. 

In the cited selection from Beck, it is clear that the service descriptions are opaque 
to the client. The service registry "reads" the service descriptions, not the client. The 
service registry checks to see if a service is loaded and, if the service is not loaded, the 
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service registry loads the service. In FIG. 5, whether the service was already loaded or 
was not loaded and thus has to be loaded by the service registry, the service registry 
returns a reference to a service adapter for the service to the client. The reference to the 
service adapter is all that the client receives in FIG. 5. The client never reads, receives, 
or sees the service description itself. Beck's service descriptions are maintained and 
accessed by Beck's service registry and only by Beck's service registry; Beck's service 
descriptions that are maintained and accessed by Beck's service registry are clearly 
opaque to Beck's client. 

Applicants maintain that Beck fails to disclose a client generating a message gate 
for accessing a service, wherein the message gate is generated according to a URI and a 
markup language schema in a service advertisement. However, even if Beck disclosed 
using a URI and a schema in an advertisement to construct a gate, Beck clearly teaches 
that the service registry, and not the client, loads the service. Since the use of the service 
registry on Beck's "service user" is taught as a key aspect of Beck's "service framework 
for computing devices", Beck's client "constructing a gate" (or downloading a service) 
would actually go against the intent of Beck's "service framework for computing 
devices", which in part is to abstract clients on a device from having to perform functions 
that Beck describes as being performed by Beck's "service framework for computing 
devices". 

For at least the reasons above, the rejection of claim 10 is not supported by the 
cited art and removal thereof is respectfully requested. Similar remarks apply to claims 
20 and 30. 

Applicants also assert that numerous ones of the dependent claims recite further 
distinctions over the cited art. However, since the rejection has been shown to be 
unsupported for the independent claims, a further discussion of the dependent claims is 
not necessary at this time. 
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Section 103(a) Rejection : 



The Office Action rejected claims 6, 16 and 26 under 35 U.S.C. § 103(a) as 
allegedly being unpatentable over Beck in view of Official Notice. Applicants traverse 
this rejection for at least the following reasons. 

The Office asserts "the use of Official Notice was previously supported by and is 
herein supported by Roberts et al. (U.S. Patent Number 6,560,633), hereinafter referred to 
as Roberts, and thus the rejection has been previously and is now maintained." 

As stated in the Reply Brief filed July 1, 2007, the Office's statement that the 
combination of Beck and Roberts "satisfies the need for a more efficient approach to 
service discovery that uses more efficient methods of describing and loading services" 
does not provide any motivation to modify Beck and is not supported by any evidence of 
record. Beck's entire invention is directed toward service discovery. Thus, one seeking 
an approach to service discovery would simply use Beck's invention, not modify it, as the 
Office contends. 

Furthermore, Beck describes a specific Java interface for the service that a 
"defines the set of operations that the service can perform on behalf of a client" (Beck, 
column 5, lines 42-43). To modify Beck with Roberts to use XML messages would be 
counter to the intended operation of Beck to employ a specific Java interface. If a 
proposed modification would render the prior art feature unsatisfactory for its intended 
purpose, then there is no suggestion or motivation to make the proposed modification. In 
re Gordon, 733 F.2d 900 (Fed. Cir. 1984). Accordingly, it would be improper to modify 
Beck's teachings to employ XML messages. 

The Office has also asserted "Beck specifically offers language independence in 
his system to allow the data transfer and other possible service implementations to be 
written in any programming language." However, the fact that Beck teaches that service 
implementation may be written in any programming language actually supports 
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Applicants' argument. As is well understood in the art, XML is a markup language, and 
is not a programming language. Furthermore, modifying the programming language in 
which Beck's service implementation is developed does not provide any motivation to 
express a message specified in a schema in a markup language that includes XML, as 
required by the specific limitations in Applicants' claim. 

In the Examiner's Answer of May 4, 2007, the Office maintains that "the 
combination of Beck and Roberts does disclose the data representation language 
comprising XML Roberts clearly teaches the use of XML in the context of expressing 
messages sent to invoke a service." Applicants can find nothing in Roberts that teaches 
or suggests the use of XML "in the context of expressing messages sent to invoke a 
service ." Nor did the Office provide any citations from Roberts in regard to this 
assertion. However, Roberts does disclose the use of XML, and XML is a markup 
language. 

In the Examiner's Answer, the Office goes on to assert "Thus the combination of 
Beck and Roberts teaches the limitation in question as discussed in the rejection in 
section (9) above." Applicants note that claim 6 depends from claim 1, and Applicants 
have clearly shown in that Beck does not anticipate claim 1 as the Office asserts. Thus, 
on this basis alone, the combination of Beck and Roberts does not teach the limitations of 
claim 6. 

In the Examiner's Answer, the Office goes on to assert "Concerning the 
appellants' statements about motivation to combine the references, it is maintained that 
the stated motivation in the above rejection is sufficient. See the paragraphs discussing 
the combination of Beck and Roberts in the rejection in section (9) above." Applicants 
have responded to this assertion. The Office's statement that the combination of Beck 
and Official Notice "satisfies the need for a more efficient approach to service discovery 
that uses more efficient methods of describing and loading services" does not provide any 
motivation to modify Beck and is not supported by any evidence of record. Beck's entire 
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invention is directed toward service discovery. Thus, one seeking an approach to service 
discovery would simply use Beck's invention, not modify it, as the Office contends. 

Furthermore, the Office's stated motivation to combine the references is merely 
conclusory. Neither Beck nor Roberts disclose any motivation to combine the two 
references. Specifically, neither Beck nor Roberts disclose any motivation to use XML 
in Beck's system as the Office argues. Furthermore, the Office's argument that XML 
could be used in Beck as the Office asserts is without merit, as is indicated below. 

Applicants remind the Office that obviousness cannot be established by 
combining or modifying the teachings of the prior art to produce the claimed invention, 
absent some teaching or suggestion or incentive to do so. In re Bond, 910 F. 2d 81, 834, 
15 USPQ2d 1566, 1568 (Fed. Cir. 1990). In addition, the showing of a suggestion, 
teaching, or motivation to combine prior teachings "must be clear and particular .... Broad 
conclusory statements regarding the teaching of multiple references, standing alone, are 
not 'evidence'." In re Dembiczak, 175 F.3d 994, 50 USPQ2d 1614 (Fed. Cir. 1999). The 
art must fairly teach or suggest to one to make the specific combination as claimed. That 
one achieves an improved result by making such a combination is no more than hindsight 
without an initial suggestion to make the combination. The Office has failed to provide a 
proper prima facie case of obviousness. 

In the Examiner's Answer of May 4, 2007, the Office goes on to assert 
"Furthermore, the appellant has stated that 'To modify Beck to use XML messages would 
be counter to the intended operation of Beck to employ a specific Java interface.' 
However, this is incorrect. Beck specifically offers language independence in his system 
to allow the data transfer and other possible service implementations to be written in any 
programming language. See Beck, column 6, lines 63-65." Applicants have previously 
responded to this assertion. The fact that Beck teaches that service implementation may 
be written in any programming language actually supports Applicants' argument. As is 
well understood in the art, XML is a markup language, not a programming language. 
One of ordinary skill in the art would easily recognize the distinction between markup 
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languages and programming languages. Beck does not teach or suggest, or provide any 
motivation for, writing service implementations in markup languages. By definition, a 
markup language is "a particular type of language used to describe or represent data or 
content". Markup languages are not programming languages, are instead used to describe 
or represent data or content, and are not designed or intended for "writing service 
implementations." Furthermore, modifying the programming language in which Beck's 
service implementation is developed does not provide any motivation for a client 
accessing a service by sending a markup language (XML) message, as required by the 
specific limitations in Applicants' claim. 

In the Examiner's Answer, the Office goes on to assert "Here it is noted that the 
appellant has made no mention of the teachings of Roberts as cited in the rejection. The 
appellant is reminded that the rejection is based on the combination of Beck and Roberts, 
both of which are directed toward expressing messages sent to invoke services." Again, 
contrary to the Office's assertion, Applicants can find nothing in Roberts that teaches or 
suggests the use of XML "in the context of expressing messages sent to invoke a 
service ." Furthermore, the Office has not provided any specific citations from Roberts in 
regard to this assertion for the Applicants to respond to. However, Roberts does disclose 
the use of XML, and XML is a markup language. That Roberts discloses the use of 
XML, and that XML is a data representation language, appears to be the only thing of 
substance in regards to Roberts and Office's assertion that a combination of Beck and 
Roberts teaches the limitations of claim 6. 

In the Examiner's Answer, the Office goes on to assert "The appellant is 
reminded that one cannot show nonobviousness by attacking references individually 
where the rejections are based on combination of references. The appellant is again 
directed to the combination in the rejection above." Applicants have shown that Beck 
does not anticipate claim 1, from which claim 6 depends. Roberts does disclose the use 
of XML, and XML is a data representation language. Furthermore, the Office's 
argument that XML could be used in Beck as the Office asserts is without merit, as is 
indicated above. For example, XML is not a programming language, and thus is not 
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usable in Beck in the manner proposed by the Office. Moreover, Roberts only describes 
XML in its traditional use for representing data. Roberts does not teach the use of XML 
for messages sent to invoke a service, which is not something that XML was designed 
for. 

Furthermore, even if Beck and Roberts were combinable and were 
combined, the results would not be anything like what is disclosed in claim 6 of the 
instant application. Combining Beck's "Service framework for computing devices" 
with Roberts' "Method for creating network services by transforming an XML runtime 
model in response to an iterative input process", if possible, would not produce what is 
recited in claim 6 of the instant application. The results of such a combination would 
simply be an embodiment of Beck's "Service framework for computing devices", which 
does not anticipate what is recited in claims 1 and 5, that uses XML for some purpose. 

For at least the reasons above, the rejection of claim 6 is not supported by the 
prior art and removal thereof is respectfully requested. Similar remarks apply to 
claims 16 and 26. 
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CONCLUSION 



Applicants submit the application is in condition for allowance, and an early 
notice to that effect is respectfully requested. 



If any fees are due, the Commissioner is authorized to charge said fees to 
Meyertons, Hood, Kivlin, Kowert, & Goetzel, P.C. Deposit Account No. 501505/5181- 
64900/RCK. 

Respectfully submitted, 

/Robert C. Kowert/ 

Robert C. Kowert, Reg. #39,255 
Attorney for Applicants 
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